Client Access Server Architecture in Exchange 2010 (part 3)

3.3. Exchange Control Panel

The Exchange Control Panel (ECP) is a completely new Web application. For end users, it provides a way to configure mail options, as shown in Figure 8. ECP is not only used seamlessly with OWA, but it is also used in Outlook 2010 when a user manages voicemail options.

ECP is not only for end users, but is also used by administrators for organization-level management. Figures Figure 8 and Figure 10 show some of the functionality provided to administrators. Figure 4-9 illustrates how an administrator can create and edit mailboxes, create groups and contacts, and administer roles. Service Pack 1 adds support for Syndicated Admins. Prior to Service Pack 1, administrators must have a mailbox to access ECP. With Syndicated Admins it is now possible to log on to ECP without having a mailbox. For example, you can use the Add-RoleGroupMemeber cmdlet to grant an administrator account to the 'OrganizationConfiguration' role. This admin account does not have a mailbox, but is able to open the ECP and perform administrative operations. Pre-SP1, if the account did not have a mailbox, the Add-RoleGroupMember cmdlet would fail. This is useful for companies that require administrators to have two accounts for security role separation and do not want administrative accounts to be mail-enabled.

Figure 10 shows an example of the new multi-mailbox search feature that allows users who have the Discovery Management role to perform searches based on keywords or other criteria.

3.4. Exchange ActiveSync

Exchange ActiveSync (EAS) is the Exchange feature that syncs mailbox information with mobile phones. Mobile clients can sync e-mail, contacts, calendar data, and tasks. Microsoft has licensed ActiveSync technology to other mobile phone manufacturers, such as Apple Inc., Nokia, Palm, Google, and Sony Ericsson. It is up to the licensee to decide which features of the ActiveSync protocol to implement.

One feature of ActiveSync is DirectPush technology. DirectPush allows the mobile phone to maintain a connection to Exchange and receive updates in real time as opposed to polling the server for new mail.

Exchange 2010 includes the ability to generate ActiveSync Reports. An administrator runs the Export-ActiveSyncLog cmdlet to generate a report with the following information included:

• Exchange ActiveSync Usage Report Used to give information related to total bytes sent and received, item counts, and item types.

• Hits Report Used to see the total number of sync requests per hour, and number of unique devices syncing.

• HTTP Status Report Used to summarize the overall performance of the Client Access server.

• Policy Compliance Report Reports on the number of fully compliant, partially compliant, and non-compliant devices syncing with the organization. Compliancy depends on the level of enforcement the mobile device implements.

• User Agent List Reports the total number of unique users sorted by the mobile phone's operating system.

Administrators now have access to a wealth of information that helps with capacity planning and service level management.

Another great advancement since Exchange 2007 is the security policies for mobile devices. In Exchange 2007, an administrator has the ability to define a security policy and enforce the policy on a per-user basis. This is problematic for users who use multiple devices because the policy affected every device. If not all of the user's devices fully enabled all of the security features, the user would have to either have all devices enabled or no devices enabled. Exchange 2007 gave administrators control at the device level, using deviceID to define ActiveSync device access rules. Exchange 2010 expands this functionality with several new capabilities. An administrator can define the default action for when a new device attempts its initial sync. The possible actions are to allow, block, or quarantine the device. If an administrator configures quarantine, the user receives a notification that the request for device syncing is being reviewed, while the administrative account configured will receive notification to approve the request. You configure this feature with the Set-ActiveSyncOrganizationSetting cmdlet with the DefaultAccessLevelAdminMailRecipients parameters. You can then configure specific device policies that override the default by using the new-ActiveSyncDeviceAccessRule and cmdlet. In Service Pack 1, administration of policies and devices was added to the ECP. Again, you must set the access level. Additionally the rule can be based on the following characteristics:

• Device model

• Device type

• Device operating system

• Device user agent

Users and administrators can view this information for existing ActiveSync partnerships using OWA to view the mobile phone details. For example, a phone partnership may show the following:

• Device Name: Touch Pro

• Device Model: HTC Touch Pro T7272

• Device Type: PocketPC

• Device OS: Windows CE 5.2.19965

• Device User agent: MSFT-PPC/5.2.19965

The administrator can use this information to build a policy specific to this device type, name, and so on. For example, if the administrator wants to always allow PocketPC device types under any circumstance, she would use the following cmdlet:

New-ActiveSyncDeviceAccessRule -QueryString PocketPC -Characteristic
DeviceModel -AccessLevel Allow

With this policy in place, all PocketPCs will be allowed to sync regardless of specific features the phone supports. Currently, these policies can only be managed through EMS cmdlets. The default ActiveSync policy allows any device to synchronize.

3.5. Internet Calendar Sharing

An interesting new feature in Service Pack 1 is for the ability to share calendars externally without federation. Similar to federated sharing, an administrator must enable and configure the feature to be available. Once enabled, users can share their calendar with anyone through OWA. By default, Internet Calendar Sharing is disabled. There are two types of URLs that can be published: restricted and public. With restricted URLs, the URL is obfuscated and must be sent to the external user directly. Public certificates, on the other hand, can be searchable on the Internet. This is shown with examples in Table 3.

Additional security measures are in place to protect Exchange because this feature exposes data to anonymous external users. First, the feature was created with total isolation from other Exchange resources. Sharing was implemented with a dedicated virtual directory. Second, the application uses a separate application pool. Third, the http access is limited to the dedicated virtual directory. Finally, throttling is enabled to prevent excessive resource consumption. Requests are throttling both on requests per mailbox and limits on CPU utilization per Client Access Server.